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Verfahren, System und Gateway, die einen End-zu-End gesfcherten Zugriff 

auf WAP-Dienste erlauben. 

Die vorliegende Erfindung betrifft eln Verfahren, mit welchem 
ein Mobilteilnehmer mit einem WAP-tauglichen Endgerat auf einen WAP 
oder WEB-Server zugreifen kann. 

WAP (Wireless Application Protocol)-Server, welche WAP basierte 
Dienste zur Verf ttgung stellen, sind an sich schon bekannt Insbesondere 
sind auf WAP-basierte Dienste im Bereich von e-commerce und von finan- 
ziellen Instituten erhaitlich. 

Sokhe Dienste veriangen eine gesicherte PaketQbertragung 
zwischen den Endbenutzern und dem Server des Dienstanbieters. Die ge- 
wdhniiche und vom WAP-Forum empfohlene Losung verwendet die WTLS- 
Protokollschkht (Wireless Transport Layer Security); dieses Verfahren kann 
jedoch nur zum sichem der PaketQbertragung zwischen den Endgeraten 
und einem (beispielsweise vom Mobilfunknetzbetreiber verwalteten) Gate- 
way verwendet werden. in diesem Gateway wird eine ProtokollGber- 
setzung zum Sicherheitsprotokoll SSL 3.1 oder zum TLS 1.0 durchgefuhrt. 

Das Prinzip einer mit diesem Verfahren gesicherten Daten- 
Qbertragung ist schematisch auf der Figur 2 dargestellt. Mit dem Bezugs- 
zeichen 1 ist ein WAP taugllches Endgerat, beispielsweise ein WAP-taug- 
liches GSM-Mobilfunktelefon (Global System for Mobile Communication) 
dargestellt, das sich uber ein digitales Mobiif unknetz 2 mit einem vom Be- 
treiber dieses Netzes verwalteten Gateway verbinden kann. Das Endgerat 1 
e nth a It ein Browser. Mit 5 ist ein Server eines Dienstanbieters, beispiels- 
weise eines Finanzinstituts oder eines Anbieters im e-commerce Bereich, 
dargestellt. Dteser Server kann auf eine Datenbank 51 zugreifen, in welcher 
WEB und/oder WAP-Seiten gespeichert sind. Die WEB oder WAP-Seiten 
kdnnen beispielsweise HTML-, WML-, JAVA-Script-. WML-Script-, usw., 
Dokumente enthalten. 



Der Benutzer des Endgerats 1, der auf eine WEB-oder WAP-Seite 
in der Datenbank 51 zugreifen kann, muss zu diesem Zweck eine mlt WTLS- 
Diensten gesicherte Anf rage durch das Gateway 3 zum Server 5 senden. 
Diese Anf rage wird im Gateway 3 durch alle Protokollschichten eines Kon- 

5 vertierungsmoduls 30 entschiusselt, und dann in eine mitTLS oder SSL 
gesicherte Anfrage ubersetzt, die uber ein TCP/IP Netz 4 an den Server 5 
gesendet wird. Im Server 5 kann ein anderes Ubersetzungsmodul vorge- 
sehen werden, das diese Anfrage in ein eigenes Format konvertiertr 
welches vom Datenbankverwaltungssystem 51 verstanden werden kann. 

10 Die Antwort vom Server 5, beispielsweise der Inhalt elner WEB oder WAP- 
Seite, wird in der anderen Richtung uber das Gateway 3, wo es umkon- 
vertiert wird f zum Endgerat 1 gelertet. 

Dieses Verfahren erlaubt keine echte End-zu-End Verschlusse- 
lung; Daten und Pakete mussen im Gateway 3 entschiusselt und wieder 
is verschlusselt werden, damit die ProtokollQbersetzung durchgefOhrt wird. 
Fur viele Anwendungen ist eine solche Sicherheitslucke jedoch nicht 
akzeptierbar. 

Ein Ziel der vorliegenden Erfindung ist es, ein neues sichereres 
Datenubertragungsverfahren zwischen einem Endgerat und einem WAP 
20 oder WEB-Server anzubieten. 

Ein anderes Ziel ist es r ein neues Verfahren anzubieten, mit 
welchem eine End-zu-End gesicherte Verbindung zwischen einem WAP- 
tauglichen Endgerat und einem WAP oder WEB-Server hergestellt werden 
kann. 

25 Ein weiteres Ziel ist es, ein neues Verfahren anzubieten, welches 

mit jedem WAP-taug lichen Endgerat das WTLS verwendet, eingesetzt 
werden kann, insbesondere mit Endgeraten, die eirte Serverauthentifi- 
zierung basierend auf einem RSA-Schlussel, auf X.509v3 Zertif ikaten, auf 
RC5 oder auf anderen Sicherheitsprotokollen gemass WAP oder WTLS, bzw. 

30 auf weiteren digitalen Zertif ikaten, verwenden. 
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Gemass der vorliegenden Erfindung werden diese Ziele ins- 
besondere durch die Merkmale der unabhangigen AnsprQche errekht. 
Weitere vorteilhafte AusfQhrungsformen gehen ausserdem aus den ab- 
hangigen AnsprQche n und der Beschreibung hervor. 

5 Insbesondere werden diese Ziele durch ein Verfahren errekht, in 

welchem das benannte Endgerat eine Anf rage fur den benannten Server 
an ein WAP-Gateway sendet, wobei die Sicherheit in der Luftschnittstelle 
zwischen dem benannten WAP-tauglichen Endgerat und dem benannten 
Gateway auf WTLS (Wireless Transport Layer Security) basiert, wobei der 

10 benannte Server eine SSL und/oder TLS Protokollschicht enthalt, wobei die 
Konversion zwischen WTLS und SSL und/oder TLS in einem vom Verwalter 
des benannten Servers verwalteten gesicherten Gebiet erfolgt, und wobei 
die Pakete, die vom benannten Endgerat gesendet werden, vom be- 
nannten Gateway zum benannten gesicherten Gebiet weitergeleitet 

15 werden, ohne alle Pakete, die wahrend einer Session ubertragen werden, 
zu entschlQsseln. 

Die Pakete werden durch eine sogenannten Tunnelschicht durch 
das Gateway ubertragen, ohne dass sie entschlQsselt werden. Dadurch 
bleibt der Inhalt selbst dem Betreiber des Gateways unbekannt. Die Pakete 
20 werden dann erst beim Server des Dienstanbieters in einem Proxy (soge- 
nannten E2ES-Proxy) entschlQsselt und mit dem Zertif ikat einer vertrauten 
Drittinstanz verifiziert. 

Ausserdem werden diese Ziele durch ein Verfahren erreicht, mit 
welchem ein Mobilteilnehmer mit einem WAP-tauglichen Endgerat auf 

25 einen WAP oder WEB-Server zugreifen kann, wobei das benannte Endgerat 
eine Anfrage fOr den benannten Server an ein WAP-Gateway sendet in 
welchem ein Browser im benannten Endgerat die Portnummer der bean- 
tragten WEB oder WAP-Seite extrahiert und in die zum benannten Gate- 
way gesendeten Pakete kopiert, und in welchem die benannten Pakete im 

30 benannten Gateway in Abhangigkeit von dieser Portnummer weiter- 
geleitet werden. 
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Ausserdem werden diese Zlele dadurch errecht, dass die Anf rage, 
die von einem Endgerat uber ein Gateway an einen WEB oder WAP-Server 
gesendet wird, mit WTLS End-zu-End gesichert wird. 

Vorzugsweise kann im Gateway zwischen Sessionen, die kon- 
s ventionell behandelt werden sollen und Sessionen, die gemass der vor- 
liegenden Erfindung weitergeleitet werden sollen, unterschieden werden. 

Im Folgenden werden anhand der beigefugten Zeichnung bevor- 
zugte Ausf uhrungsbeispiele der Erfindung naher beschrieben: 

Die Figur 1 vergleicht die Protokollschichten in einem WAP- 
10 Protokoll-Stapel und im Internet Protokoll-Stapel. 

Die oben beschriebene Figur 2 zeigt das Prinzip einer gesicherten 
DatenQbertragung gem ass dem normalen WAP-Protokoll. 

Die Figur 3 zeigt das Prinzip einer gesicherten DatenQbertragung 
gemass einer ersten Variante der Erfindung. 

is Die Figur 4 zeigt das Prinzip einer gesicherten DatenQbertragung 

gemass einer zweiten Variante der Erfindung. 

Die Figur 5 zeigt das Prinzip einer gesicherten DatenQbertragung 
gemSss einer dritten Variante der Erfindung. 

Die Figur 3 zeigt das Prinzip einer ersten Variante der Erfindung. 

20 Diese Figur zeigt ein in einem digitalen Mobilfunknetz 2 angemeldetes 
WAP-taugllches Endgerat 1, beispielsweise ein WAP-taugliches GSM- 
Mobitfunktelefon oder einen WAP-tauglichen tragbaren Rechner. Mit 
diesem Gerat kann ein Programm, beispielsweise ein WAP-Browser, 
ausgef Qhrt werden, das sich ais Kunde mit einem WAP und/ oder WEB- 

25 Server 5 verbinden kann und somit auf Daten in diesem Server zugreifen 
kann. 



Der WAP- oder WEB-Server 5 enthait WML und/oder HTML- 
Seiten, die beispielsweise von einem Dienstanbieter (beispielsweise einem 
Finanzinstitut und/oder einem Anbieter im Bereich e-<ommerce) angeboten 
werden. Es wird oft von Dienstanbietern und Endbenutzern gewQnscht, 

5 dass die Session die auf gebaut wird wenn ein Benutzer auf mehrere Seiten 
zugreift, geskhert wird. Insbesondere ist es oft notig, dass manche Daten, 
die in beiden Richtungen zwischen dem Endgerat 1 und dem Server 5 uber- 
tragen werden, End-zu-End gesichert werden und dass keine Drittpartei, 
nicht einmai der Mobilfunknetzbetreiber, diese Daten entschlOsseln kann. 

io Ausserdem wird eine gegenseitige Authentisierung des Dienstanbieters 
und des Mobilbenutzers benotigt. 

Der Benutzer des Endgerats kann eine geskherte Seite erreichen, 
beispielsweise um eine Transaktion durchzufuhren, indem er beispielsweise 
auf den entsprechenden URL einer gesicherten oder nicht gesicherten Seite 
is klickt. Der vom Dienstanbieter definierte URL der Seite kann beispielsweise 
http://www.sp1. com :50443 lauten, wobei http://www.sp1 .com die URL* 
Adresse des Dienstanbieter und 50443 seine Portnummer Ist. In Wap 
werden hingegen die fortlaufenden Portnummerbereiche 920x 
angewendet. 

20 Erfindungsgemass werden die URL in den WML und/oder HTML- 

Seiten der Dienstanbieter so verfasst, dass die gewunschte Sessionsart (End- 
zu-End gesichert. Standard gesichert oder ungesichert ) aus diesem URU 
unter'anderem aus der URL-Adresse und/oder aus der Portnummer, er- 
mittelt werden kann. 

25 Mit dem Bezugszeichen 3 ist ein ebenfalls dem Mobilfunknetz 2 

angeschlossenes Gateway dargestellt. Das Gateway nimmt die Pakete vom 
Benutzer 1 entgegen und entschlQsselt das oder die ersten Pakete in jeder 
Session, bis eine Anwendung 314 die Portnummer und die URL der ge- 
wunschten WEB oder WAP-5eite aus den Paketen extrahieren kann. 

30 Sobald diese Angaben gefunden worden sind, bestimmt die 

Anwendung 314 anhand den vom Verwalter des Gateways angegebenen 
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Angaben, wle die Pakete bearbeitet werden sollen. Insbesondere bestimmt 
die Anwendung, ob die Session zwischen dem Endgerat 1 und dem Server 5 
End-zu-End gesichert werden soil. Dies ist beispielsweise dann der Fall 
wenn sich die Portnummer (beispielsweise 50443) in einer vom Admini- 
5 strator des Gateways aufgebauten Liste befindet. 

Das Gateway 3 verwendet eine zusatzliche Protokollschicht 310 
(Tunnelschicht), die von der Anwendung 314 gesteuert wird (Pfeil 315). 
Wenn die Session gesichert werden soli, wird die Tunnelschicht 310 so 
gesteuert, dass alle nachfolgenden Pakete der Session in transparenter Art 
to durch das Gateway gef Qhrt und an die Zieladresse des Servers 5 weiter- 
geleitet werden, ohne konvertiert und vor all em ohne entschlQsselt zu 
werden. 

Die immer noch mit WTLS gesicherten Pakete der Session werden 
dann uber das Netz 4 weitergeleitet und vom Server 5 im gesicherten Ge- 
ls biet des Dienstanbieters entgegengenommen. Das Netz 4 kann beispiels- 
weise aus dem Internet oder aus elner gemieteten Telefon-Linie bestehen. 
Der Server 5 umfasst ein Proxy 52 welches spater erlautert wird, ein kon- 
ventionelies Gateway 50, und eine Datenbank 51, in welcher ein WEB- und/ 
oder WAP-lnhalt abgelegt ist. 

20 Das Proxy 52 im Server 5 des Dienstanbieters wird so aufgebaut, 

dass es WTLS-gesicherte Sessionen entgegennehmen kann. Es umfasst 
vorzugsweise einen kompletten WAP-Protokoll-Stapel und kann somit 
durch vom Fachmann leicht durchfQhrbare Anpassungen von 
standardisierter Software realisiert werden. In diesem Proxy werden 

25 empfangene mit WTLS gesicherte WDP-Datagramme mit dem Zertif ikat 
einer vertrauten Drittinstanz geprQft, entschlQsselt und in normale TCP-IP- 
Datagramme ubersetzt, wobei die HTTP-Session optional mit SSL gesichert 
werden kann. Die TCP-IP konvertierten Pakete werden an den WAP- oder 
WEB-Server 50 weitergeleitet, der eventuell eine andere 

30 Protokollkonvertierung durchfOhrt, damit die empfangene Abf rage vom 
Datenbanksystem 51 bearbeitet werden kann. 
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Als Alternative konnen die Datagramme mit einem Session- 
SchlQssel ver- und entschlusselt werden, dssen Schlussel mit Hilfe eines 
zertifizierten, offentlfchen SchlQssei wahrend der 
SchlQsselvereinbarungsphase generiert werden. 

5 Die Antwort vom WEB bzw. WAP-Server 50, zum Beispiel die 

gewunschte WEB- oder WAP-Seite # wird vom Server 50 in die andere 
Richtung gesendet, im Proxy 52 Qbersetzt und mit WTLS-Diensten gesichert 
und durch die "Tunnelschicht" 310 im Gateway 31 an das Endgerat 1 des 
Benutzers geieitet, wobei die gesamte Verbindung zwischen Server 5 und 

10 Endbenutzer 1 mit WTLS gesichert wird. 

Datagramme, die aufgrund des enthaltenen URL und/oder 
Portnummer keine End-zu-End gesicherte DatenQbertragung verlangen, 
werden im Gateway 31 gemass der konventionellen vom WAP-Forum 
empfohlenen L6sung durch alle Schichten des Protokolls im Gateway 2 
15 entschlusselt mit TLS/SSL wieder gesichert und an die in den Paketen 

angegebene URL-Ad resse weitergeleitet. Beispielsweise werden Sessionen 
mit der Portnummer 80 wie gewohnliche HTTP-Sessionen behandelt und 
weitergeleitet. 

Antworten vom Server 5 (beispielsweise die gewiinschten WEB 
20 oder WAP-Seiten) die keine WTLS-Sicherung zwischen Server und Gate- 
way 3 verlangen, werden von der Proxy-Anwendung 524 durch eine 
Tunnelschicht 520 im Proxy durchgefuhrt (Pfeil 315) und erst im Gateway 3 
mit WTLS-Diensten gesichert. 

Diese Variante verlangt keine Anderungen vom Browser im 
25 Endgerat 1 1 und nur ein relativ efnf aches Proxy 53 beim Dienstanbieter 5, 
das WTLS-Sessionen entgegennehmen kann. Die Software-Implementation 
des Gateways 3 kann sich jedoch als schwierig erweisen. 

Die zweite Variante, die auf der Figur 4 dargestelit wird, erlaubt 
es F dieses Problem durch eine leicht durchf Qhrbare Anpassung der Anwen- 
30 dung (zum Beispiel des Browsers) im Endgerat 1 zu vermeiden. In dieser 



8 



Variante wird die URL-Adresse und die Portnummer der verlangten WEB 
oder WAP-Seite vom Browser 10 in jedes Paket (WDP-Datagramm) der 
Session kopiert Diese Pakete werden dann fiber das Mobilfunknetz 2 an 
das Gateway 3 gesendet, wo die Portnummer und die URL analysiert 
5 werden, urn zu emnitteln wie die Pakete weiterbehandelt werden sollen. 

Diese Variante hat den Vorteil, dass die Analyse und die Weiter- 
behandlung der Pakete in den unteren Schichten des Protokolls, unter 
anderem in der WDP und/oder WTLS-Schicht, durchgefuhrt werden kann 
und dass sle somit nur mmimale Anpassungen des Gateways 3 verlangt. 

io Eine Tabeile 321 im Gateway 3 oder in einem nicht dargesteltten 

Router vor dem Gateway gibt an, wie die Pakete je nach Portnummer und 
URL behandelt werden solien und insbesondere weiche Pakete transparent 
durch die Tunnelschicht 320 gehen sollen. Diese Tabeile kann vorzugsweise 
vom Administrator des Gateways 3 konfiguriert und geandert werden, 

is ohne dass das Gateway neu gestartet werden muss, damit die 

(Configuration wahrend des Betriebes aktualisiert werden kann. Daten in 
der Tabeile kdnnen vorzugsweise nur vom Administrator geandert werden, 
oder von Personen mit Administratorenrechten. 

Die Tabeile im Gateway 3 konnte beispielsweise folgende Zeilen 
20 enthalten: 





Eingegebene URL 
Adresse 


Neue Adresse (vom 
Gateway erteilt) 


Bemerkung 




Adresse 


Port- 
nummer 


Adresse 


Port- 
nummer 




1 


138.10.20.30 


8040 


140.50.60.70 


12345 


Pakete mit dieser Adresse 
werden auf transparente 
Weise an die neue Adresse 
geleitet. Die Portnummer 
wird ersetzt (Mapping). 


2 




50443 


**** 


50443 


Stern-Joker erlauben eine 
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Bedingung fOr alle Server 
mtt der gleichen Port- 
nummer zu setzen 


3 


138.10.20.40 


* 


138.10.20.40 


* 


Wie oben, jedoch ohne 
DNS-Lookup 


4 


www.sp1.conn 


* 


www.spl.com 


* 


Alle URL vom sp1 mQssen 

U V>l 1 UIV 1 vll 11 ICuUUU %\ 


5 


www.sp1.com 


80 


www.sp1.com 


80 


Alle Verbindungen mit 
Portnummer 80 durch die 
Tunnelschicht 


6 


www.spl.ch 


50443 


wwwjspl xh 


50443 


spl verlangt, dass alle 
Sessionen mit der Port- 
nummer 50443 durch die 
Tunnelschicht geleftet 
werden. 


/ 


www.sp2.ch 




www.sp2.ch 




sp2 verlangt. dass alle 

JCSXIVIICII II1IL UtSf WkJt IT 

nummer 443 durch die 
Tunnelschicht geleitet 
werden. Damit wird kein 
SSL mit dem Port 443 
verwendet. SSL kann dann 
beispielsweise vom Proxy 
verwendet werden. 
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Der Administrator des Gateways 3 wird vorzugsweise den Dienst- f . 

anbietern einen Bereich von URL-Adressen und/oder Portnummern zur 
Verfugung stellen. Dienstanbieter SP1, SP2, usw. konnen dann eine oder 
5 mehrere URL, oder Portnummern, oder Kombinationen aus beiden, fur sich 
reservieren und clen Administrator 3 anweisen, Pakete mit dieser URL 
und/oder Portnummer transparent weiterzuleiten* 
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Die Figur 5 zeigt als Beispiel, wie die Pakete, die von ver- 
schiedenen Endbenutzern 1i bis 1 4 gesendet werden, vom Gateway 3 in 
Abhangigkeit ihrer URL-Adresse und/oder Portnummer behandeit werden. 

Das dargestellte System umfasst in diesem Beispiel drei Server 5 1# 
5 5 2 und 5 3 von drei verschiedenen Dienstanbietern sp1, sp2 und sp3. Die vier 
foigenden Seiten werden im ersten Server 5i (bzw. 5 2 ) abgelegt: 

■ eine ungesicherte WEB-Seite mit der Adresse 
www.sp1.com:80 (bzw. www.sp2.com:80) 

" eine WEB-Seite mit der Adresse www.spl xom:443 (bzw. 
to www.sp2.com:443), die nur mit SSL gesichert wird (keine 

End-zu-End Sicherheit) 

■ eine WEB-Seite mit der Adresse www.spl .com:50443 (bzw. 
www.sp2.com:50443), die mit WTLS gesichert wird (End-zu- 
End Sicherheit) 

15 ■ eine WAP-Seite mit der Adresse wap.spl .com: 50443 (bzw. 

wap.sp2.com:50443), die mit WTLS gesichert wird (End-zu- 
End Sicherheit) 

Im Server 5 3 des dritten Dienstanbieters sp3 werden nur zwei 
Seiten abgelegt: 

20 ■ eine ungesicherte WEB-Seite mit der Adresse 

www.sp3.com:S0 

■ eine WEB-Seite mit der Adresse www.sp3.com:443, die nur 
mit SSL gesichert wird (keine End-zu-End Sicherheit) 

Der erste Benutzer 1 1 will auf die gesicherten Seiten 
25 www.spl. com :443 und www.sp1.com: 50443 des Dienstanbieters SP1 im 
Server 5i zugreifen, indem er GET(URL) Abfragen mit entsprechenden URL 



P-^H&^N^Og^ -OO ; 13:49 patents a ^El^Sl u ^ «PPI i 32 724 96 62 ^RSD; 



11 



an das Gateway 3 sendet Das Gateway 3 erkennt anhand der Ta belle 321 
und des im Datagramm enthaltenen URL und/oder der Portnummer, 
welche Slcherheiten von diesen Seiten verlangt werden. Im ersten Fall (SSL 
Sicherheit) werden alle Datagramme der Session im Gateway 3 entschlusselt 
5 und eine Gbersetzung von WTLS zu SSL wird durchgefuhrt. Im zweiten Fall 
(End-zu-End Sicherheit mit WTLS) werden alle Datagramme der Session 
transparent an den Server 5 t weitergeleitet, ohne dass sie entschlusselt 
werden. 

Der zweite Benutzer 1 2 will auf die Seite www.sp2.com: 5043 3 des 
io Dienstanbieters sp2 im Server 5 2 zugreifen, die eine End-zu-End Sicherheit 
verlangt. Datagramme mit dieser Adresse werden im Gateway 3 erkannt 
und transparent durch die Tunnelschicht an den Server 5 2 geleitet. 

Der dritte Benutzer 1 3 will auf die Seite www.sp3.com:443 des 
Dienstanbieters sp2 im Server 52 zugreifen, die eine mit TLS/SSL gewahr- 
15 leistete Sicherheit verlangt. WTLS-gesicherte Datagramme mit dieser 

Adresse werden im Gateway 3 erkannt durch alle Schichten des Protokoll- 
Stapels Obersetzt, mit TLS/SSL gesichert und an den Server 5 3 weitergeleitet. 

Der vierte Benutzer 1 4 will auf die ungesicherte Seite 
www.sp3.co m:80 des Dienstanbieters sp2 im Server 5 2 zugreifen. WTLS- 
20 gesicherte Pakete mit dieser Adresse werden im Gateway 3 erkannt, durch 
alle Schichten des Protokoll-Stapels Obersetzt und an den Server 5 3 weiter- 
geleitet, ohne sie durch das Netz 4 zu sichern. 

Diese Variante verlangt nur minimale Anderungen vom Gateway 
3. Allerdings mussen die Browser-Anwendungen in den Endgeraten 1 leicht 
25 angepasst werden, was slch bei vielen Anbietem als schwierig erweisen 
kann. 

Wir werden jetzt eine dritte Erfindungsvariante beschreiben, die 
diesen Nachteil vermeidet. 
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In dieser Variante werden Sessionen die eine End-zu-End Sicher- 
heit verlangen anhand der URL-Adresse und/oder der Portnummer wie in 
der ersten oder zweiten Variante erkannt. Statt die Sessionen durch die 
Tunnelschicht transparent weiterzuleiten, sendet das Gateway in diesem 
5 Fail einen standardisierten Redirect-Befehl mit der in der Tabelie 321 ange- 
gebenen Adresse und Portnummer des Dienstanbieters und mit anderen 
Parameter fQr die Identifizierung vom Gateway 5, wie Dial-In Nummer, an 
das Endgerat 1. 

Die Weiterleitungsadresse (Adresse, Portnummer, Dial-In 
10 Nummer, usw..) im Redirect-Befehl wird vorzugsweise aus einem vom WAP 
oder WEB-Server 5 zugdnglich gemachten Dokument extrahiert. Der 
Redirect-Befehl kann auch dieses oder ein anderes Dokument oder die 
Adresse eines solchen Dokuments enthalten, in welchem die 
Weiterleitungsadresse enthalten ist. Im Dokument konnen vorzugsweise 
is verschiedene Adressengebiete mit Stringmuster, beispielsweise mit *, 
angegeben werden. 

Die Anwendung im Mobilgerat 1, die diesen Redirect Befehl 
entgegennimmt, reagiert, indem sie jetrt die schon vorher an das Gate- 
way 3 gesendeten Pakete wieder direkt an die im Redirect-Befehl an- 
20 gegebene Adresse des Dienstanbieters sendet. 

Alle Pakete in der Session werden dann direkt zwischen dem 
Endgerat 1 und dem Server 5 ubertragen, bis der Endbenutzer einen 
anderen URL sendet, der vom Server 5 nicht bearbeitet werden kann 
(beispielsweise wenn sich die entsprechende gewOnschte Seite nicht auf 
25 diesem Server befindet). In diesem Fall wird die Session vom Server 5 
unterbrochen und die nachfolgenden Pakete werden wieder an das 
Gateway 3 gesendet. 



r 
L 
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Falls keine End-zu-End Sicherheit bendtigt wird, wird kein 
Redirect Befehl vom Gateway 3 gesendet. In diesem Fall werden alle Pakete 
wahrend der gesicherten Session durch das Gateway 3 gesendet 
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AnsprGche 

1 . Verfahren, mit wekhem ein Mobihteilnehmer mit einem WAP- 
tauglichen Endgerat (1) auf einen WAP oder WEB-Server (5) zugreifen 
kann, 

5 wobei das benannte Endgerat (1) eine Anfrage fQr den benannten Server 
an ein WAP-Gateway (3) sendet, 

wobei die Sicherheit in der Luftschnittstelie (2) zwischen dem 
benannten WAP-tauglichen Endgerat (1) und dem benannten Gateway (3) 
auf WTLS (Wireless Transport Layer Security) basiert, 
10 wobei der benannte Server (5) mit dem SSL und/oder TLS 

Sicherheitsprotokoll gesichert ist, 

dadurch gekennzeichnet, dass die Konversion zwischen WTLS 
und SSL und/oder TLS in einem vom Verwalter des benannten Servers (5) 
verwalteten gesicherten Gebiet erfolgt, 
i5 und dass die Pakete, die vom benannten Endgerat (1) ge- 

sendet werden, vom benannten Gateway (3) zum benannten gesicherten 
Gebiet weitergeleitet werden, ohne alle Pakete die wahrend einer Session 
ubertragen werden zu entschlQsseln. 

2. Verfahren gemass Anspruch 1, dadurch gekennzeichnet, dass 
20 das benannte Gateway (3) die benannten Pakete zu einem Proxy (52) im 

benannten gesicherten Gebiet weiterleitet, wobei das benannte Proxy (52) 
mindestens eine Protokoilschicht des WAP-Protokoils verwendet. 

3. Verfahren gemass einem der Anspruche 1 oder 2, in welchem 
die benannten Pakete in Abhangigkeit vom URI und/oder vom Domain- 

25 name der angef ragte Seite im benannten Gateway (3) weitergeleitet 
werden. 

4. Verfahren gemass einem der vorhergehenden AnsprOche, in 
welchem die benannten Pakete abhangig von der Portnummer im be- 
nannten Gateway (3) weitergeleitet werden. 
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5. Verfahren gemass dem vorhergehenden Anspruch, In 
weichem die benannten Pakete a bhang ig von verschiedenen Portnummern 
an verschiedene gesicherte Gebiete weitergeleitet werden. 

6. Verfahren gernass einem der Anspruche 4 oder 5, in weichem 
5 die benannte Portnummer aus der URI und/oder URL der angef ragten Seite 

in einer Anwendungsschicht des benannten Gateways (3) extrahiert 
werden. 

7. Verfahren gernass Anspruch 6, in weichem die benannte Port- 
nummer wahrend einer Session nur aus einer begrenzten Anzahi von 

10 Paketen extrahiert wird, 

und in weichem das Weiterleiten von mindestens einem fol- 
genden Paket von dieser benannten extrahierten Portnummer abhangig 
ist. 

8. Verfahren gemass Anspruch 7, in weichem ein Proxyserver (52) 
15 im benannten gesicherten Gebiet die URI und/oder die Portnummer der 

empfangenen Pakete extrahiert, und in weichem der benannte Proxyserver 
(52) dem benannten Gateway (3) einen Befehl zurucksendet, wenn er ein 
Paket mit einer anderen URI und/oder mit einer anderen Portnummer 
empfangt. 

20 9. Verfahren gemass einem der Anspruche 4 oder 5, in weichem 

die benannte Portnummer aus dem benannten URI und/oder URL der an- 
gefragten Webseite im benannten Endgerat (1) extrahiert wird- 

10. Verfahren gemass Anspruch 9, in weichem die benannte Port- 
nummer von einem Browser aus dem URI und/oder URL der angefragten 

25 Webseite extrahiert wird. 

1 1 . Verfahren gemass einem der AnsprQche 8 oder 9, in weichem 
der Browser im benannten Endgerat (1) die benannte Portnummer in den 
benannten Paketen erst dann kopiert, wenn eine End-zu-End gesicherte 
Verbindung beantragt ist. 
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1 2. Verfahren gemass einem der Ansprtiche 3 bis 1 1, in welchem 
die benannten Pakete im benannten Gateway (3) an ein gesichertes Gebiet 
weitergeleitet werden wenn sich die benannte Portnummer in einem 
vorbestimmten Bereich befindet. 

5 13. Verfahren gemass Anspruch 1, dadurch gekennzeichnet, dass 

wenn eine End-zu-End gesicherte Verbindung beantragt 1st, das benannte 
Gateway (3) einen Redirect-Befehl zum benannten Endgerat (1) sendet. 

14. Verfahren gemass dem vorhergehenden Anspruch, in 
welchem der benannte Redirect Befehl zeitlich begrenzt ist. 

10 1 5. Verfahren gemass Anspruch 13, in welchem ein Proxy Server 

(52) im benannten gesicherten Gebiet die URI und/oder die Portnummer 
der empfangenen Pakete extrahiert, und einen Redirect Befehl zurQck zum 
benannten Endgerat (1) sendet, sobaid die Session zum benannten Gate- 
way (3) weitergeleitet werden soli. 

is 16. Verfahren gemass Anspruch 13, in welchem den benannten 

Redirect-Befehl eine Weiterleitungsadresse enthait, die aus einem vom 
benannten WAP oder WEB-Server (5) zuganglich gemachten Dokument 
extrahiert wird. 

17. Verfahren gemass dem Anspruch 13. in welchem den 
20 benannten Redirect-Befehl ein Dokument enthait, in welchem die 

Weiterleitungsadresse enthalten ist. 

18. Verfahren, mit welchem ein Mobilteilnehmer mit einem WAP- 
tauglichen Endgerat (1) auf einen WAP oder WEB-Server (5) zugreifen 
kann, 

25 wobei das benannte Endgerat (1) eine Anfrage fur den benannten Server 
(5) an ein WAP-Gateway (3) sendet, 

dadurch gekennzekhnet, dass ein Browser im benannten Endgerat (1) die 
Portnummer der beantragten WEB oder WAP-Seite extrahiert und in zum 
benannten Gateway (3) gesendete Paketen kopiert. 
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und dass die benannten Pakete im benannten Gateway (3) in Abhangigkeit 
von dieser Portnummer weitergeleitet werden. 

19. Gateway (3), das rn'rt WTLS-gesicherte Datagramme von WAP- 
tauglichen Endgeraten entgegennehmen und In SSL-gesicherte-Abfragen 
Qbersetzen kann, 

dadurch gekennzeichnet, dass es Datagramme erkennen 
kann, die in transparenter Weise weitergeleitet werden sollen und dass es 
diese Datagramme ohne sie zu entschlusseln weiterleiten kann. 

20. Gateway gemass dem vorhergehenden Anspruch, in welchem 
die benannten Pakete in Abhangigkeit vom URI und/oder vom Domain- 
name der angef ragten Seite weitergeleitet werden. 

21 . Gateway gemass einem der AnsprQche 1 9 oder 20, in welchem 
die benannten Pakete in Abhangigkeit von der Portnummer im benannten 
Gateway (3) weitergeleitet werden. 

is 22. Gateway gemass dem vorhergehenden Anspruch, in welchem 

die benannten Pakete abhangig von verschiedenen Portnummern an 
verschiedene geslcherte Gebiete weitergeleitet werden. 

23. Gateway gemass einem der AnsprQche 21 oder 22, in welchem 
die benannte Portnummer aus dem URI und/oder URL der angef ragten 

20 Seite in einer Anwendungsschicht des benannten Gateways (3) extrahiert 
werden. 

24. Gateway gemass Anspruch 21, in welchem die benannte Port- 
nummer wahrend einer Session nur aus einer begrenzten Anzahl von 
Paketen extrahiert werden, 

25 und in welchem das Weiterleiten von mindestens einem 

folgenden Paket von dieser benannten extrahierten Portnummer abhangig 
ist. 
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Zusammenfassung 

Verfahren, mit welchem ein Mobilteilnehmer mit emem WAP- 
tauglichen Endgerat (1) auf einen WAP oder WEB-Server (5) zugreifen 
kann, 

5 wobei das benannte Endgerat (1) eine Anfrage fOr den benannten Server 
an ein WAP-Gateway (3) sendet, 

wobei die Sicherheit in der Luftschnittstelle (2) zwischen dem 
benannten WAP-tauglichen Endgerat (1) und dem benannten Gateway (2) 
auf WTLS (Wireless Transport Layer Security) basiert, 
10 wobei der benannte Server (5) mit dem SSL und/oder TLS Sicher- 

heitsprotokoll gesi chert ist # 

wobei die Konversion zwischen WTLS und SSL und/oder TLS in einem 
vom Verwalter des benannten Servers (5) verwalteten gesicherten Gebiet 
erfolgt, 

15 und wobei die Pakete, die vom benannten Endgerat (1) gesendet 

werden, vom benannten Gateway (3) zum benannten gesicherten Gebiet 
weitergelertet werden, ohne dass alle Pakete die wahrend einer Session 
Qbertragen werden entschlusselt werden. 



(Fig. 3) 
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